Concepts similar to SPN are known to exist in a number of forms. A process monitoring application called IPM had previously been developed as a joint effort between Siemens and Heller AG. IPM is currently a product that runs on the Sinumerik 840D. IPM is owned by Siemens and marketed by Heller as an optional feature for its machines. IPM has a software component known as a “Signal Correction Chain.” The signal correction chain serves the role of signal correction as described herein in the discussions related to process monitoring. Like SPN, the signal correction chain is composed of computation blocks that serve the role of executing a specific type of equation and the output from a computation block is routed to the input of another computation block. Unlike SPN, the signal collection in IPM has highly limited topologies, enables only a single input and a single output from each block, and may be limited in how the blocks are parameterized as a consequence of the data format used to represent the blocks. Furthermore, the signal correction concept has not been used for servo control or simulation purposes.
A commercial product SIMULINK® is sold and marketed by “The Mathworks” company. SIMULINK® is a large and powerful software package that is essentially a differential equation solver that uses block diagrams to represent the dynamic systems to be simulated. SIMULINK® blocks are similar to SPU's, in that they can have one or more inputs, one or more outputs, may be parameterized, and serve some specific computational role. The entire block diagram or “model” may be represented as a data format. Normally SIMULINK® runs in a non-embedded environment such as on a PC platform or Unix workstation. However, the Mathworks offers as an extension to SIMULINK®, a product known as REAL TIME WORKSHOP®. REAL TIME WORKSHOP® has the ability to compile SIMULINK® models to executable code that runs on a certain target real time platform. One major difference between REAL TIME WORKSHOP® in combination with SIMULINK® and the SPN is that REAL TIME WORKSHOP® generates, compiles, and links run-time code while the SPN uses data to configure already existing compiled and linked code. Other differences are that SPN uses XML to represent its definition and provides dedicated interfaces to the motion controller for the purpose of monitoring, failure detection, servo control, and simulation. Other unique aspects of SPN are described in the description of details herein.
Alternatives
Several alternative strategies for providing a mechanism for flexibly specifying signal processing networks have been considered. One alternative is to automatically generate executable code from a higher level description of the SPN. High level descriptions could be accomplished using modeling environments such as SIMULINK®, a CASE tool, or XML. One disadvantage of auto-generated code may be the possibility that the user of such software might feel uncomfortable knowing that the code had been auto-generated. Another consideration for auto-generated code is in the area of software testing—how can an environment with auto-generated code be tested in a comprehensive way?
Another alternative is an open architecture interface that allows a software developer to generate a fixed model as a loadable executable code. The execution algorithms are fixed but may be parameterized by data, for example as XML. The advantage of a general purpose OA interface is that programming languages such as C or c++provide the possibility of developing highly elaborate algorithms that might not be possible by combining instances of a finite set of SPU types into a network. One disadvantage of such an interface may be that it limits the use cases (fields of application). Taking the process monitoring use case as an example, new ideas for signal correction and failure detection require development of new source code. This requires coordination of software releases between the products that provide the setup utility and the products that provide the real time signal correction. In the case of servo control, the setup engineer often may not have the skills or tools required to develop, build, and deploy real time software in the field at the machine.